What Dashboard Design Can Learn From Games

A bit of background

In a mind-expanding article, Susie Lu compares exploratory data visualisations like dashboards to a [[!Choose Your Own Adventure]] story. Not only does this mean dashboard design can learn from storytelling framing, she also brings in comparisons to game design.

As a storytelling and game design nerd, I am naturally all for this and probably more than a little biased. However, game nerd or not, I think it's a legitimately helpful framing device, especially as I work with a lot of data visualisations and dashboard in my days as a UX designer. As such, I'm collecting thoughts on the topic here.

Dashboards as games

  • Game design storytelling and HUD (head's up displays) can be a useful mental model for a dashboard.
  • Design for multiple visits (plays) by creating easily recognised features and tools. Users should want to come back to answer their questions.
  • Clearly mark what you can interact with.
  • Make it easy to save and share.
  • Consider the user's 'inventory'. What tools do they need? Do they change over time? Do they persist?
  • Branch the narrative based on the data and/or user's goal.
  • Provide the right insights for the right users (players).

Game areas of inspiration/overlap

Zoom out from the graphics and subject matter to the abstract interactions and tools. Strategy games and RPGs are particularly useful to look at as they tend to involve more information displays, context switching, and resource management. The point is not to take examples literally and port them to dashboard, but to think about the interactions and mental models involved and how they might overlap with adventuring through data (which can be an alien world sometimes).

  • HUD (Head's up display): what persistant tools are you presented with? How do you use them interact to with the changing world?
  • Mini-maps: how does the game help you maintain context as you explore?
  • Levels of abstraction: how do you shift views and levels of abstraction for different needs, from a exploring to conflict, inspecting elements to managing those items or units?
  • Information overlays: video games tend to make use of cues (quest markers, health indicators, interaction highlights) which pack in information without obscuring the context (that is, the game world).
  • Navigating sequential and contextual information: RPGs especially provide dense menus and class trees where you might be investigating points of interest and how they relate to the wider context. These are a challenge to execute well.
  • Recovery mechanisms: How do you save? How do you get back on track when you're lost? When you load up a game after not playing for ages, how do you discover where you left off or what's changed?
  • Progress and status indicators: How do you see if you're closing in on a goal? If you're running low on health? If you should challenge that enemy or run away (ex: how serious is this problem the data has helped you notice)?
  • Relationships: How do your decisions affect the world? How do the different views link? In a game, there are strong relationships between actions. Likewise, what are the relationships between various charts in the dashboard? How do you navigate between them and connect information in meaningful ways?

Divergent framing to keep in mind

Many games are designed to be completed or progress through. Dashboards and exploratory visualisations do not have a predefined end state. This does not mean they don't have a workflow (quite the opposite, it's crucial to understand how users move through the data), but the end is when the user achieves their goal/answers their question, which can occur at various points and may involve people, systems, and tools beyond any one dashboard. [[!Emergent games]] (ex: Minecraft) can be interesting to look at here as the story emerges through play and there is not an end point, similar to exploratory data visualisations/dashboards.

Games traditionally focus on success. A gameover is a bad thing. Depending on the type of data you're working with, dashboards may need to highlight areas of failures/problems as much as (or more than) successes. In games, this normally takes place at a more granular level (say, in a mission), but the overall aim is to progress through. I worked on a security application previously and while a sense of progress was important (yay, you fixed something!) for the user experience, the most crucial dashboard feature were around identifying risks and vulnerable areas. Think of a tower defense game: you don't need to see where the walls are grand, you need to know where they've been breached and you need to know NOW.

Use what helps, forget the rest

The comparisons could go on, but I am likely already straining the relationship here. The key is not looking at any game element too literally but zooming out to think about mental models for exploring a given context and achieving a goal (which may change). That doesn't mean dropping a mini-map and health bar into your dashboard (though not gonna lie, I kinda want to see a giant interactive visualisation with a mini map now).

At the higher levels of abstraction, you'll start seeing overlaps everywhere. On one dashboard-centric product I worked on, we compared a flow to shopping and 'checking out' the items you needed to take action on. The point is not to fixate on the metaphor but find analogies that others understand and help improve the design.

I think looking at game design can be a useful tool, in that sense. In my own experience, game design and storytelling are useful framing devices which help me zoom out to think about user quests and the flows and tools that facilitate that. The key is not to fall so in love with the metaphor that you fixate on shoehorning the design around specific elements or models at the cost of the user experience. There may be similarities between games and dashboards, but the most important mental model to consider is the user's.

References